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Abstract 


This document defines extensions to the Layer Two Tunneling Protocol 
version 3 (L2TPv3) for support of structure-agnostic and structure- 
aware (Circuit Emulation Service over Packet Switched Network 
(CESOPSN) style) Time-Division Multiplexing (TDM) pseudowires. 
Support of structure-aware (Time-Division Multiplexing over IP 
(TDMoIP) style) pseudowires over L2TPv3 is left for further study. 


Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the 
"Internet Official Protocol Standards" (STD 1) for the 
standardization state and status of this protocol. Distribution of 


this memo is unlimited. 
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not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
than English. 
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1. Introduction 


This document defines extensions to the Layer Two Tunneling Protocol 
Version 3 (L2TPv3) for support of structure-agnostic [RFC4553] and 
structure-aware (CESoOPSN style, see [RFC5086]) Time-Division 
Multiplexing (TDM) pseudowires. Structure-agnostic encapsulation of 
TDM bit-streams over L2TPv3 is described in [RFC4553], Figure 2b; 
Circuit Emulation Service over Packet Switched Networks (CESoPSN), 
structure-aware encapsulation is described in [RFC5086], Figures lc 
(TDM data packets) and 4a (CE application signaling packets). 
However, the order of the CESOPSN Control Word (CW) and RTP header 
(if it is used) MUST match between the TDM data and CE signaling 
packets. 


Setup of structure-aware TDM pseudowires using the encapsulations 
described in [RFC5087] has been left for further study. 


Setup and maintenance of TDM pseudowires (PWs) in MPLS networks using 
LDP is described in [RFC5287]. 
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1.1. Conventions Used in This Document 


In this document, we refer to the "control plane" as meaning the 
packets that contain control information (via Attribute-Value Pairs 
(AVPs)) and the mechanism that handles these packets. We also refer 
to the "data plane" as meaning the packets that contain transported 
user data. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


2. L2TPv3 Extensions 
The L2TPv3 Control Connection is responsible for 3 main operations: 
1. Establishment and validation of a pseudowire (PW) session. 
2. Ending (tearing down) of a pseudowire session. 
3. Transferring of End Point status. 


Tearing down of the session for a TDM pseudowire is performed 
following the L2TPv3 tear-down operations as described in Section 
3.4.3 of [RFC3931]. 


[RFC5086] and [RFC4553] describe how to transfer the Attachment 
Circuit (AC) status via the data plane. Therefore, the Set-Link-Info 
(SLI) message described in [RFC3931] SHOULD NOT be used for conveying 
this status for the PWs in question. 


[RFC3931] specifies that the Circuit Status Attribute-Value Pair 
(AVP) MUST be present in the ICRQ/ICRP (Incoming-Call-Request / 
Incoming-Call-Reply) messages. It also specifies that the N bit in 
this AVP should be set during the PW setup, even if the specific AC 
does not provide any way to convey the "new AC" indication. 
Accordingly, the Circuit Status AVP for the PWs in question, when 
used in the ICRQ/ICRP messages, MUST always have both N and A bits 
set. 


The next sections describe the extensions to L2TPv3 for establishment 
and validation of TDM pseudowire sessions. 


There are two new AVPs for the Session Management messages. One AVP 


describes the TDM pseudowire attributes. The second AVP describes 
the RTP attributes for this TDM pseudowire. 
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2.1. TDM PW Attribute-Value Pair (AVP) (ICRQ, OCRQ) 


0 1 2 3 
0 L2 3 45 6 7-8 9-0 1-234 36 Be GOL 2 3° AD) 6. 7B Oe OL 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|M|H| rsvd | Length | Vendor Id (IETF) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Attribute Type (99) | Reserved |sp |cas| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Bit Rate | Payload Bytes | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 
AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 
L2: 


The Bit Rate field contains the value that represents the bit rate of 
the local AC in the units of 64 Kbit/s, encoded as an unsigned 16-bit 
integer. Its usage for all types of TDM PWs employs the following 
semantics: 


1) For structure-agnostic emulation, this parameter MUST be set to 
one of the following values (see [RFC4553]): 


a) Structure-agnostic El emulation - 32 
b) Structure-agnostic T1 emulation: 
i) MUST be set to 24 for the basic mode 
ii) MUST be set to 25 for the "Octet-aligned T1" mode 
c) Structure-agnostic E3 emulation - 535 
d) Structure-agnostic T3 emulation - 699 


2) For CESoPSN PWs, this parameter MUST be set to the number of DSO 
channels in the corresponding attachment circuit. 


Note: For structure-agnostic Tl emulation, the values 24 and 25 do 
not reflect the exact bit rate and are used for convenience only. 


Note: The semantics of the Bit Rate field defined above are 


consistent with those of the CEP/TDM Bit-Rate interface parameter as 
defined in [RFC5287]. 
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The Payload Bytes field contains the value representing the number of 
TDM payload bytes in the PW packet and is used with the following 
semantics: 


1) For structure-agnostic emulation, any value of the Payload Bytes 
can be specified. 


2) For CESoPSN PWs: 


a) The specified value MUST be an integer multiple of the number 
of DSO channels in the corresponding attachment circuit. 


b) In addition to that, for trunk-specific NxDSO with Channel- 
Associated Signaling (CAS), the number of the trunk frames per 
multiframe fragment (value resulting from the Payload Bytes 
divided by the number of DSO channels) MUST be an integer 
divisor of the number of frames per corresponding trunk 
multiframe. 


The Reserved bits MUST be set to 0 on transmission and MUST be 
ignored on reception. 


The SP bits define support for the CESoPSN-application signaling 
packets (see [RFC5086]) and MUST be used as follows: 


1) Set to ’01’ for the CESoPSN PWs carrying TDM data packets and 
expecting CE application signaling packets in a separate PW. 


2) Set to '10’ for a PW carrying CE application signaling packets 
with the data packets in a separate PW. 


3) Set to ’11’ for a CESoPSN PW carrying both TDM data and signaling 
packets. 


4) Set to ’00’ for Structure-Agnostic Time-Division Multiplexing over 
Packet (SAToP) PWs and for CESoPSN PWs not using separate 


signaling packets. 


The CAS bits define the trunk type for trunk-specific CESoPSN 
services with CAS. These bits MUST be set to: 


1) For trunk-specific CESOPSN with CAS: 
a) ’01’ in the case of an El trunk 
b) ’10’ in the case of a T1/ESF trunk 


c) ’11’ in the case of a T1/SF trunk 
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2) '00’ for all the other TDM pseudowire types 
2.2. RTP Attribute-Value Pair (AVP) (ICRQ, OCRQ, ICRP, OCRP) 


0 1 2 3 
Ok 234-5 6° 7 8° 9-0 1 2.3 4°59 6°7 8 9 0 Lf 2:3 4 5 6 728 9 OL 
t—+—-+-4+-+-4+-4-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-t-4+-4-t-4+-4t-4-4+-4t-4-4-4-4-4 
|M|H| rsvd | Length | Vendor Id (IETF) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +H 

| Attribute Type (100) |D | PT |c| Reserved 

t—+—-+-4+-+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-4t-4+-4-4t-4+-4-4-4+-4+-4-4-4-4-4 
| Reserved | Timestamp Clock Frequency | 
t—+—-+-4+-+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4+-4-4-4t-4+-4-4+-4+-4-4-4+-4-4-4+-4-4-4 
| SSRC | 
t-+—-+-4+-+-4+-4-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-4t-4+-4-4+-4+-4-4-4+-4+-4-4-4-4-4 


Presence of this AVP indicates that the RTP header is used in the TDM 
pseudowire encapsulation. Use or non-use of the RTP header MUST 
match for the two directions of a TDM PW. This AVP MAY be hidden 
(the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 
0. The Length (before hiding) of this AVP is 16. 


The D bit indicates the timestamping mode (absolute or differential) 
in the RTP header. These modes are described in, e.g., Section 4.3.2 
of [RFC4553]. If the D bit is set to 1, then the differential 
timestamping mode is used; otherwise, the absolute timestamping mode 
is used. Timestamping modes can be used independently for the two 
directions of a TDM PW. 


The C bit indicates the ordering of the RTP header and the Control 
Word as following: 


o If the C bit is set to 1, the RTP header appears after the Control 
Word in the data channel of the TDM pseudowire. This mode is 
described in [RFC4553] and [RFC5086] as SAToP/CESoOPSN encapsulation 
over IPv4/IPv6 PSN with L2TPv3 demultiplexing, respectively. 


o If the C bit is set to 0, the RTP header appears before the Control 
Word. This mode is described as the old mode of the SAToP/CESoPSN 
encapsulation over L2TPv3 in Appendix A of [RFC4553] and Appendix C 
of [RFC5086], respectively. 


PT is the payload type expected in the RTP header. A value of 0 
indicates that the receiver shall not check payload type to detect 


malformed packets. 


Timestamp Clock Frequency is the clock frequency used for 
timestamping in units of 8 KHz. 
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SSRC indicates the expected value of the synchronization source 
(SSRC) ID in the RTP header. A 0 in this field means that the SSRC 
ID will not be used for detecting misconnections. Since L2TP 
provides an alternative security mechanism using cookies, if the 
cookie length is larger than 0, the SSRC SHOULD be 0. 


2.3. Changes in the Control Connection Management AVPs 
Control Connections that support TDM PWs MUST add the appropriate PW 
Type value(s) to the list in the Pseudowire Capabilities List AVP. 
The valid values are listed in the next section. 
2.4. Changes in the Session Management AVPs 
PW Type AVP should be set to one of the following values: 
1. Structure-agnostic emulation [RFC4553] of: 
a. El circuits - 0x0011 
b. T1 (DS1) circuits - 0x0012 
c. E3 circuits - 0x0013 
d. T3 (DS3) circuits - 0x0014 
2. Structure-aware emulation [RFC5086] of: 
a. CESOPSN basic mode - 0x0015 


b. Trunk-specific CESoPSN service with CAS - 0x0017 


TDM pseudowires use their own Control Word. Therefore, the L2- 
Specific Sublayer AVP MUST either be omitted or set to 0. 


TDM pseudowires use their own sequencing. Therefore, the Data 
Sequencing AVP MUST either be omitted or set to 0. 


Note: The Control Word (CW) used in the SAToP and CESoPSN 
encapsulations over L2TPv3 effectively represents a dedicated L2- 
Specific Sublayer. 


3. Creation of the TDM Pseudowire Session 
When an L2TP Control Connection Endpoint (LCCE) wants to open a 
Session for a TDM PW, it MUST include the TDM PW AVP (in any case) 


and the RTP AVP (if and only if the RTP header is used) in the ICRQ 
or OCRQ (Outgoing-Call-Request) message. The LCCE peer must validate 
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the TDM PW AVP and make sure it can meet the requirements derived 


from the RTP AVP (if it exists). If the peer agrees with the TDM 
AVP, it will send an appropriate ICRP or OCRP (Outgoing-Call-Reply) 
message with the matching RTP AVP (if needed). The initiator needs 


to validate that it can supply the requirements derived from the 
received RTP AVP. 


The two peers MUST agree on the values in the TDM PW AVP: 


1. Bit Rate values MUST be equal on both sides. If they are 
different, the connection will be rejected with Result Code 30 and 
Error Code 1. 


2. In the case of trunk-specific CESoPSN with CAS, the trunk type (as 
encoded in the CAS bits of the TDM AVP) MUST be the same for the 
two sides. Otherwise, the connection will be rejected with Result 
Code 30 and Error Code 2. 


3. If one side does not support the Payload Bytes value proposed by 
the other one, the connection will be rejected with Result Code 30 
and Error Code 3. 


4. If one side cannot send the RTP header as requested by the other 
side, the connection will be rejected with Result Code 30 and 
Error Code 4. 


5. If one side can send the RTP header but not with the requested 
timestamp clock frequency, the connection will be rejected with 
Result Code 30 and Error Code 5. 


If CE signaling for a CESOPSN basic PW is transported in a separate 
PW instance, then the two PW instances: 


1. MUST use the same PW type. 

2. MUST use the same values in all the fields of the TDM AVP 
excluding the SP field, which must be set to ’01’ for the TDM data 
PW and to ’10’ for the PW carrying CE application signaling. 


3. MUST both either use or not use the RIP header (and, accordingly, 
include or not include the RTP AVP). 
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4. IANA Considerations 


TANA assigned the following values according to this document: 


New L2TPv3 Pseudowire Types: 


Note 


0x0011 - Structure-agnostic El circuit 
0x0012 - Structure-agnostic T1 (DS1) circuit 
0x0013 - Structure-agnostic E3 circuit 


0x0014 - Structure-agnostic T3 (DS3) circuit 
0x0015 - CESOPSN basic mode 
0x0017 - CESOPSN TDM with CAS 


that the values listed match the values defined in [RFC4446] for 


the MPLS Pseudowire Types. 


New Attribute-Value Pair IDs: 


1 


99 - TDM Pseudowire AVP 
00 -— RTP AVP 


New Result Codes for the CDN message: 


3 


New 


0 - Result Code to indicate connection was refused because of TDM 
PW parameters. The Error Code indicates the problem. 


TDM PW specific Error Codes, to be used with 30 Result Code for 


the CDN message: 


This is a new registry for IANA to maintain within the Result Code 
AVP (Attribute Type 1) Values. Additional values may be assigned by 
Expert Review [RFC5226]. 
0 - Reserved. 
1 - Bit Rate values disagree. 
2 - Different trunk types in the case of trunk-specific CESOPSN 
with CAS. 
3 - Requested payload size too big or too small. 
4 - RTP header cannot be generated. 
5 - Requested timestamp clock frequency cannot be generated. 
5. Congestion Control 
The congestion considerations from [RFC4553] and [RFC5086] apply 


respectively to the structure-agnostic and CESoOPSN modes of this 
specification. 
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6. Security Considerations 


This document specifies only the L2TPv3-based control plane for setup 
of TDM PWs. Within this scope, there are no additional security 
considerations in addition to those discussed in [RFC3931]. 


Common data plane security considerations for the TDM PWs have been 
discussed in some detail in both [RFC4553] and [RFC5086]. On top of 
these, the L2TPv3-based data plane provides additional security 
mechanisms based on the usage of cookies. 
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